(1) Do the tests assert real behavior?

Yes. They are behavioral, not line-chasing:

• cliOAuth.test.ts — the new confirmStepUpFromStdin tests drive the actual normalization logic ("y", whitespace-padded " YES " → proceed; "n" → throws "Step-up authorization declined.") and assert the finally { rl.close() } runs (mockClose called). The connectInspectorWithOAuth block distinguishes the three real branches: AuthRecoveryRequiredError + satisfied storage (reconnect, no interactive), unsatisfied (interactive runs), plain 401 (isUnauthorizedError matches "…failed…(401)" — confirmed against core/auth/utils.ts), non-OAuth rethrow, and non-OAuth-capable rethrow. The .catch(() => {}) disconnect guard is exercised with a rejecting disconnect. Assertions are on thrown messages and spy call counts — meaningful.
• AuthTab.test.tsx — the up-arrow test writes DOWN→UP→ENTER and asserts onAuthorizeStepUp (not onCancelStepUp) fires; if UP were a no-op the selection would sit at index 1 and Enter would cancel, so the assertion genuinely pins the Math.max(0, i-1) behavior. The a/c/x test asserts the unrelated key is swallowed (counts unchanged after x), covering the return; fall-through.
• App.test.tsx — every mid-session test asserts a concrete outcome tied to a real message string, all of which I verified in source: "Refreshing authorization…" (App.tsx:843), "needs additional OAuth scopes" / "…organization before it can continue" (core/auth/oauthUx.ts:99-100, correctly EMA vs non-EMA per catalog), "were not granted" (oauthUx.ts:172-180), "enterprise…" (EmaClientNotConfiguredError, both reasons contain it), and the success/already_authorized/insufficient_scope/unsupported/skipped result branches of runOAuthAuthentication and the onAuthorizeStepUp EMA path (satisfied/interactive/failed/throws).

(2) Are the two harness additions sound / non-fragile?

Yes, both.

• Client-event registry — addEventListener/removeEventListener now maintain a Map<event, Set<fn>>; App's per-client cleanup removes exactly the fns it added, and beforeEach calls clientEvents.clear(), so there's no cross-test leak. React effects flush after render (not during dispatch), so forEach isn't mutated mid-iteration. Fine.
• runRunnerInteractiveOAuth override defaulting to the real runner — the wrapper falls through to actual.runRunnerInteractiveOAuth when override is null, so the pre-existing callback-driven tests (which drive h.cb.opts.onCallback) keep working untouched; override is reset in beforeEach. When set, it returns a deterministic { kind }. A never-resolving default runner in a fire-and-forget void (async …)() flow doesn't hang the test because the assertions poll intermediate state (callbackStart called) rather than awaiting completion. Sound.

(3) Missed edge cases / observations (minor, non-blocking)

1. "ignores auth lifecycle events from a non-selected server" is a coverage test, not a true guard test. Because the registry is keyed by event name only, fireClientEvent("oauthError", …) fires both the selected (web) and non-selected (api) handlers. Both produce the same observable side effect (web sets the message; api early-returns), so the assertion ("selected-only error" appears) would still pass even if the selectedServerRef.current !== serverName guard were removed. It exercises the early-return branch for coverage but doesn't pin its behavior. Truly asserting the guard would require firing an event for only the non-selected client, which the event-name-keyed registry can't express. Consider this a known fidelity gap rather than a fix-now item.

2. A couple of negative assertions rely on fixed ticks (e.g. await tick(); await tick(); expect(h.connect).toHaveBeenCalledTimes(1) in the "unsupported OAuth result" test). These are acceptable since the override resolves immediately and a wrongful reconnect would land within two ticks, but they're inherently the most timing-sensitive assertions in the suite if the flow ever grows an extra await.

3. runOAuthAuthentication's "skipped" (oauthInProgressRef already true → "OAuth already in progress.") branches don't appear to be directly exercised — consistent with the reported branch % staying below 100 (cli 96.4, App 90.2). Above the gate, so fine to leave.

The registry rekey is sound

clientEvents is now Map<event, Set<{client, fn}>>, addEventListener records the owning FakeClient, and removeEventListener matches by fn (each client builds its own onAmbient/onOAuthError closures, so fn is unique per client — the by-fn delete is unambiguous). clientInstances is reset in beforeEach (h.clientInstances.length = 0) alongside clientEvents.clear(), so no cross-test leak. fireClientEvent still fires every client's handler, preserving all pre-existing single-server tests. Clean.

The guard is now behaviorally asserted, not just covered

The test resolves api/web by their url (http://b / http://a from twoHttp()), fires ambient/recovered/oauthError for only api (non-selected), and asserts the frame contains neither "Refreshing authorization" nor "api-only error", then fires web and asserts both surface. This closes the exact fidelity gap I flagged: with the event-name-only registry the old test would have passed even with the guard deleted.

I verified that empirically — temporarily removing the selectedServerRef.current !== serverName guard on onAmbient (App.tsx:841) fails the test:

AssertionError: expected '…' not to contain 'Refreshing authorization'
❯ __tests__/App.test.tsx:1451

Restored after. Test passes clean at head (1 passed / 79 skipped). So the ambient and oauthError guards are now true regression guards.

One residual, genuinely-minor nuance (non-blocking)

Of the three fired events, only ambient and oauthError are behaviorally pinned. The onRecovered guard (App.tsx:846) has no distinguishable observable effect when it runs — it does setOauthMessage(null) (message is already null here) + bumps oauthRevision — so removing its guard alone wouldn't flip any assertion. That's a limitation of the handler having no visible side effect to observe, not of the test design; the two guards that can produce output are both pinned. Not worth contriving state to chase.

(2) and (3) left as-is — agreed

The fixed-tick negative assertions are fine given the override resolves synchronously, and the oauthInProgress → "skipped" branch would need a contrived concurrent-OAuth race; all three files clear the ≥90 gate without it. Reasonable to leave.